D E F E A T I N G T B S C A N F L A G S
by Havoc The Chaos
One day while removing all possible ThunderByte AV flags from one of
my viruses, I discovered a way to remove just about all flags. I will begin
with the flags I removed myself, and then proceed with flags others have
found, in order to create a full document on TBSCAN flags. Original credit
is due to myself, except where noted.
F Suspicious file access; this file might be able to infect a file
mov ax, 5701h
int 21h ; flagged as 'F'
mov ax, 5700h
inc al
int 21h ; not flagged
mov ax, 4301h
int 21h ; flagged as 'F'
mov ax, 4300h
inc al
int 21h ; not flagged
ie, anything that restores the original state of the file might be tagged.
E Flexible Entry Point; this file is designed to be able to be linked
anywhere in a file. Very common for viruses.
call $+3
pop bp ; flagged as 'E'
call $+3
int 3
pop bp ; not flagged
B Back to entry point; this file is designed to restart the program once
finished. Very common for viruses
mov ax, 100h
jmp ax ; flagged as 'B'
mov ax, 200h
shr ax, 1
jmp ax ; not flagged
S Contains a routine to search for executable (.COM or .EXE) files.
comspec db '*.COM',0 ; flagged
comspec db ').COM',0 ; not flagged, therefore
inc byte ptr [bp+offset comspec]
lea dx, [bp+comspec]
int 21h
dec byte ptr [bp+offset comspec]
; This effectively changes a search for ').COM' to '*.COM'. Get the picture?
T Incorrect timestamp. Some viruses use this to mark infected files.
Having the year higher than 2000 or the seconds higher than 59 will
set it off.
Z EXE/COM determination. The program tries to check whether a file
is a COM or EXE file. Viruses need to do this to infect a program.
cmp word ptr [bp+buffer], 'ZM' ; flagged!
cmp word ptr [bp+buffer], 'MZ' ; flagged!
cmp byte ptr [bp+buffer], 'Z' ; not flagged
cmp byte ptr [bp+buffer], 'M' ; not flagged
G Garbage instructions. Contains code that seems to have no purpose
other than encryption or avoiding recognition by virus scanners.
I have only found this when using A86. When I complied
the same virus with TASM (2 passes), the flag disappeared.
@ Encountered instructions which are not likely to be generated by
an assembler, but by some code generator like a polymorphic virus.
As quoted by Qark of VLAD:
"We will take 'OR CX,CX' as an example. It can be represented by:
db 09h,0c9h or db 0bh,0c9h
The first two-byte combination sets off the flag, the second does
not. TBSCAN is correct in flagging it, because the first 'or cx,cx'
is never produced naturally. "
In otherwords, when coding your polymorphic engine, do NOT USE DEBUG
TO GET THE OPCODES! Instead, use an assembler. When I tested mine,
I got flagged. I read this, and used debug to find "or cx,cx", and
sure enough, it was 9, 0C9h. Under an assembler, or was 0Bh, 0C9h.
U Undocumented interrupt/DOS call. The program might be just tricky
but can also be a virus using a non-standard way to detect itself.
Reference: Qark/VLAD
mov ax, 6e00h ; This one is ok.
int 21h
mov ax, 6f00h ; This one causes a flag.
int 21h
mov ax, 09191h ; This one is ok.
int 13h
mov ax, 09191h ; This one causes a flag.
int 0b6h
A Suspicious Memory Allocation. The program uses a non-standard
way to search for, and/or allocate memory.
Reference: Qark/VLAD
cmp byte ptr [0], 'Z' ; Direct MCB-Chaining
? Inconsistent exe-header. Might be a virus but can also be a bug.
Does anyone have any information on this? I know if the value in
the exe header in locations 10-18 are higher than 50 (or so), it will
be flagged, but I fail to see why. Frans must be on to something.
It is not the checksum (as I thought). I can say that much. The
file that flagged it had nothing out of the ordinary that I could
see, as in the stack was not odd, it was allocating the proper
amount of memory, and the CS:IP entry point was fine.
L The program traps the loading of software. Might be a
virus that intercepts program load to infect the software.
Simply put, trapping int 21 function 4Bh will cause this flag.
A better idea for tsr viruses is to infect on file close, and
TRUE clean it on anything else.
M Memory resident code. The program might stay resident in memory.
mov word ptr ds:[21h*4], offset int21
mov ds:[21h*4+2], es ; flagged
Direct manipulation always causes the flag to be tripped. Another
way to get the int handler established, is to tunnel (trace) and then just
call the original int 21 to do the job for you. It's either that, or have a
flag.
Well, that should take care of the most common TBScan flags.
Many people probably see the amount of Anti-Thunderbyte information
that is out there and think it is a personal attack. This couldn't be
further from the truth (at least from my standpoint). It _IS_ a good
product, although it has several things that could have been tightned up.
C'est la vie.
I would like to thank Qark for additional flag information, and also
Dark Angel of Phalcon/Skism for his help (even though it didn't lead to much
information) with the inconsistent exe-header flag. 's been fun.
- VLAD #7 INDEX -